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1 INTRODUCTION 


This is the High Altitude, Long Endurance (HALE) Unmanned Aircraft Systems 
(UAS) Command and Control (C2) Communications Functional Requirements 
Document (FRD). This document applies to communications between HALE UA 
and their associated control stations, together called UAS, operating within the 
National Airspace System (NAS). The requirements apply to Step 1 of the Access 5 
project, sponsored by the National Aeronautics and Space Administration (NASA). 


1.1 Background 

HALE UAS are increasingly being developed and used to support a broad spectrum 
of defense, civil, and commercial applications. To avoid conflict with conventional 
manned aircraft, these aircraft have typically been limited to flying in restricted 
airspace. Recently, some UA such as Global Hawk have been allowed to fly in civil 
airspace on a controlled case-by-case basis using the Certificate of Authorization 
(CoA) process. As stated in the Access 5 HALE Remotely Operated Aircraft (ROA) 
Concept of Operations (CONOPS) document, the ultimate objective is to allow these 
aircraft "to operate in all categories of airspace with the same freedom as manned 
aircraft ... and ... [be] viewed by the Air Traffic Control (ATC) system and other 
airspace users as just another member of the aviation community." 

Access 5 is a national project leading the way in enabling UA to routinely fly with 
other aircraft in the NAS. It is the intent of the Access 5 project to integrate UAS 
operations into the NAS as efficiently as possible, such that the ability of the pilot-in- 
command (PIC) to control HALE UA and interact with the ATC is comparable to 
pilots of manned aircraft. The Access 5 project consists of a strategic 
govemment/industry alliance to develop standards, regulations, and procedures; 
demonstrate the technologies; and implement infrastructure necessary to meet 
national priorities. For example, regulations and procedures are needed to certify 
UAS, while technologies and procedures are needed for maintaining a level of safety 
equivalent to that of manned aircraft. 

Access 5 plans call for integrating HALE UAS into the NAS through a four-step 
process: 

Step 1 : Routine operations above Flight Level 430 (FL430) (43,000 feet) through 
pre-coordinated airspace 

Step 2 : Routine operations above FL180 (18,000 feet) through pre-coordinated 
airspace with emergency landings at pre-coordinated airports 

Step 3 : Routine operations above FL180 through C, D, and E airspace with 
emergency landing at pre-coordinated airports 
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Step 4 : Routine operations above FL180 through C, D, and E airspace with 
emergency landings at any UAS designated airport 


Currently, the primary issue for flying UA in the NAS is flight safety. To be 
accepted in the NAS, these aircraft must be flown with a level of safety equivalent to 
that of manned aircraft. That is, the UA must not present a hazard to people or 
property in the air or on the ground, and must adapt to dangerous and unexpected 
situations as effectively as manned aircraft. To promote safety, these aircraft must 
operate reliably, maintain safe separation distances, and be responsive to direction 
from control authorities. 

To ensure flight safety, it is vital that UAS have reliable, available, high quality C2 
communication links. These links are needed to transmit commands to control the 
UA and to receive status information and data from the UA. This information may 
include health and status, situation awareness, and possibly relayed digitalized voice. 
The security of the link must be maintained to prevent unauthorized access to the 
control of the UA. 

1.2 Purpose 

This document establishes requirements for communications that facilitate C2 of 
HALE UA operating within the NAS. The document applies to the general HALE 
UA industry, particularly civil and commercial applications. 

The requirements focus on functional capabilities for elements of the C2 
Communications System. The document includes standards for communications 
operation, reliability, and safety that apply to HALE UAS, and may propose 
modifications or additions to the existing aviation infrastructure. 

The requirements are stated in a design- and technology-neutral manner. That is, 
they are not dependent on the exact design or method for providing the functionality. 
On occasion, text accompanying a requirement may include examples of design or 
technology items, intended for illustration only. 


1.3 Scope 

The C2 Communications System requirements in this document apply to Step 1 of 
the Access 5 project, which addresses HALE UA above FL430. This flight level 
corresponds to the en route phase of flight operations. 

Requirements in this document apply specifically to C2 communications between the 
UA and the Air Vehicle Control Station (AVCS), called the C2 link (i.e., the UA- 
AVCS link). Communications between the UA and ATC (UA-ATC link) and 
between the AVCS and ATC (AVCS-ATC link) are covered in a separate document, 
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the HALE ROA ATC Communications Step 1 Requirements Document. 

Requirements in this document apply specifically to the C2 link under normal 
operating conditions, including handover of control and possible predictable outages. 
Requirements that apply to the C2 link when it has an unplanned outage are covered 
in the Contingency Management Requirements Document. 

The scope of the C2 communications requirements encompasses both the content of 
the communications and the mechanism of the communications. The requirements 
specified in this document for Step 1 address the following high level functions: 

• Perform information exchanges for UA operations 

• Provide communications procedures and protocols 

• Provide communications to control safe flight and UA operations 

• Provide secure C2 link 

• Provide C2 link connectivity 

It is expected that most of the requirements specified for Step 1 will apply to all 
subsequent steps of the Access 5 project. Requirements specific to Steps 2, 3, or 4 
will be added to subsequent releases of this document as needed during the 
corresponding steps of the project. 


1.4 Document Organization 

Section 1 states the background, purpose and scope of this requirements document, 
including its relationship to the Access 5 program. 

Section 2 lists the applicable reference documents cited in this specification. 

Section 3 presents an overview of the C2 Communications System for HALE UAS. 

Section 4 states the functional requirements for C2 Communications for HALE 
UAS. This section also provides assumptions that underlie the requirements. 

Section 5 defines the verification process for the C2 Communications requirements 
for HALE UAS. A verification matrix for the defined requirements is included. 

Appendix A provides an acronym list. 

Appendix B defines terminology used in this document and is intended as a basis for 
consistent use of these terms. 

Appendix C contains C2 communications capabilities excerpted from the Access 5 
Functional Requirements Document (FRD). 
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Appendix D provides a brief review of the NAS Modernization Program as the 
background information needed for the gap analysis as appropriate. 

Appendix E provides the data links currently supported in the Aeronautical 
Telecommunications Network (ATN) standard. Again, the purpose is to facilitate 
the related information in one source for the gap analysis as needed. 

Appendix F provides guidelines for C2 Communications System performance. 

Appendix G describes the methodology used to establish the requirements in this 
document. 

Appendix H reports a status and comparison review on other standards activities, 
specifically, a review of the minutes of RTCA SC-203 and an evaluation of the draft 
NATO STANAG 4660. The latter is a draft standard aimed at interoperable C2 data 
links for Unmanned Systems. 
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2 APPLICABLE DOCUMENTS 


The following documents are applicable reference documents. They are considered 
part of this requirements document to the extent they are directly referenced by 
specific sections of this document. 


2.1 Government Documents 

2.1.1 Federal Aviation Administration (FAA) Specifications 


Document No. 

Title 

Version/Date 

FAA-E2958 

System Requirements Document Next 
Generation Air/Ground Communications 
(NEXCOM) 

Version 2.0, 
October 22, 2003 

NAS-SR-1000 

NAS System Requirements Specification 

October 1994 

NAS-SS-1000 

NAS System Specification, Volume 1 

September 1994 


2.1.2 FAA Orders 


Document No. 

Title 

Version/Date 

FAA Order 
1600.54 

FAA Automated Information Systems 
Handbook 


FAA Order 
1600.66 

Telecommunications and Information 
Security System Policy 


FAA Order 
6000.36A 

Communications Diversity 

November 14, 1995 

FAA Order 
6040.15 

National Airspace Performance Reporting 
System 


FAA Order 
7610.4 

Special Military Operation 

19 February 2004, 
Change 1 dated 5 August 
2004 


2.1.3 Other FAA Documents 


Document No. 

Title 

Version/Date 

TSO-C169 

VHF Radio Communications Transceiver 
Equipment Operating within the Radio 
Frequency Rang 1 1 7.975 to 1 37 
Megahertz 

May 17, 2004 
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2.1.4 Other Government Documents 


Document No. 

Title 

Version/Date 

14 CFR Parti 

Aeronautic and Space 


47 CFR Part 2 

Frequency Allocations and Radio Treaty 
Matters; General Rules and Regulations 

October 1998 

47 CFR Part 87 

Aviation Services 

October 1998 

NTIA (Chapters II, 
V, VII, X and 
Annex B) 

Manual of Regulations and Procedures for 
Federal Radio Frequency Management 

May 2003 Edition, 
May 2004 Revision 

Office of Secretary 
Defense 

Airspace Integration Plan for Unmanned 
Aviation 

Draft 

OMB Circular A- 
130 

Management of Federal Information 
Resources 



2.2 Non-Government Documents 

2.2.1 International Civil Aviation Organization (ICAO) Standards 


Document No. 

Title 

Version/Date 

ICAO Annex 2 

Rules of the Air 

9 tn Edition, July 1990 with 
Amendment 37 dated 
February 28, 2003 

ICAO Annex 10 

Aeronautical Telecommunications - 
Volume II, Communication Procedures 

1 st Edition, July 1995 with 
Amendment 79 dated 
November 25, 2004 

ICAO Annex 10 

Aeronautical Telecommunications - 
Volume III, Part 1 - Digital Data 
Communications 

1 st Edition, July 1995 with 
Amendment 79 dated 
November 25, 2004 

ICAO Annex 17 

Security 

7 th Edition, April 2002 with 
Amendment 10 dated 
April 2002 

ICAO 9705 

Manual of Technical Provisions for the 
Aeronautical Telecommunication Network 
(ATN) 

3 ra Edition 
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2.2.2 Industry Standards 


Document No. 

Title 

Version/Date 

ETSI EN 301 473 

SES; AES Operating under the 
Aeronautical Mobile Satellite Service 
(AMSS) 

VI .3.0, June 2004 

RTCA 

DO-160D 

Environmental Conditions and Test 
Procedures for Airborne Equipment 

July 29, 1997 with Change 
1 dated December 14, 
2000; Change 2 dated 
June 12, 2001; and 
Change 3 dated 
December 5, 2002. 

RTCA 

DO-219 

Minimum Operational Performance 
Standards for ATC Two-Way Data Link 
Communications 

August 27, 1993 

RTCA DO-224A 

Signal-in-Space Minimum Aviation 
System Performance Standards (MASPS) 
for Advanced VHF Digital Data 
Communications Including Compatibility 
with Digital Voice Techniques 

September 13, 2000 with 
Change 1 dated 12 
October 2001 and Change 
2 dated 27 August 2002 

RTCA 

DO-240 

Minimum Operational Performance 
Standards for Aeronautical 
Telecommunications Network (ATN) 
Avionics 

July 29, 1997 

RTCA 

DO-258 

Interoperability Requirements for ATS 
Applications Using ARINC 622 Data 
Communications 

September 13, 2000 

RTCA 

DO-264 

Guideline for Approval of the Provision 
and Use of Air Traffic Services Supported 
by Data Communications 

December 14, 2000 

STANAG 4660 

Interoperable C2 Data Link for Unmanned 
Systems 

Draft version 1 .2, 
January 6, 2006 


2.2.3 Access 5 Project Documents 


Document No. 

Title 

Version/Date 


Access 5 Functional Requirements 
Document (FRD) 

Rev 3, 

January 2006 


Access 5 HALE ROA Concept of 
Operations (CONOPS) 

Rev 2, 
March 2005 


HALE ROA ATC Communications Step 1 
Requirements Document 

Draft Version 3.0, 
May 31, 2005 


Contingency Management Requirements 
Document 

Revision D, 
March 31, 2005 

Memo AV50991- 
006 

CONOPS and FRD Assumptions 

June 22,2004 


2.2.4 Research Literature 


Document No. 

Title 

Version/Date 

National Institute of 
Standard and 
Technology (NIST) 

Methods for Determining the Level of 
Autonomy to Design into a Human 
Spaceflight Vehicle: A Function Specific 
Approach 

PerMIS Conference 2003 

NIST Special 
Publication 1011 

Terminology for Specifying the Autonomy 
Levels for Unmanned Systems 

Version 1 .0, 
January 2004 
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2.3 Order of Precedence 


The requirements in this document are set forth to supplement or further develop 
requirements in FAA documents, with the objective of being integrated with FAA 
documents. It is expected that requirements in this document do not conflict with 
those in FAA documents or other Government documents. When the requirements 
in this document conflict with non-FAA or non-Government documents, this 
document shall have precedence. 
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3 SYSTEM OVERVIEW 


This section presents an overview of the C2 Communications System for HALE 
UAS, including a description of the Step 1 concept, components of the system, and 
types of data exchanged using the communications link. 


3.1 Step 1 Capability 


For this document, the C2 Communications System focuses on Step 1 of the four 
steps defined in the Access 5 Project Plan. Step 1 focuses on achieving safe, 
reliable, and routine operational access for UA at or above 43,000 feet (FL430). The 
ascent and descent are limited only to restricted or pre-coordinated NAS. The 
takeoff and landing through restricted or pre-coordinated airspace is the purview of 
the organization authorizing flight. Figure 1 shows the high level operational 
perspective for Step 1 . 



Figure 1. Step 1 Focuses on UA Operations above 43,000 Feet, with Ascent / Descent 

through Pre-Coordinated Airspace 


For Step 1, all necessary communications are at the en route phase and are 
established to ensure safe and reliable HALE UA flight. The AVCS is equipped 
with sufficient communications means to facilitate the PIC to perform operations 
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safely and satisfactorily. 


3.2 System Components 


The HALE UAS C2 Communications System provides the connection between the 
PIC and UA to support operations that include but are not limited to flight control, 
communications relay, and subsystem monitoring and control. Figure 2 shows an 
overview of the HALE UAS C2 Communications System, its components, and 
interfaces. In the figure, internal interfaces illustrate connectivity between 
constituent components, while external interfaces provide the context in which the 
C2 Communications System operates within the UAS. 


HALE UAS C2 
Communications 
System 



Legend 


Interface to 
External System 

Internal Interface 


HALE UAS 
C2 Comm 
Component 


External 

System 


Figure 2. HALE UAS C2 Communications System 


The generic components of the C2 Communications System include the following: 

• AVCS C2 Communications Equipment Component - systems and equipment 
at the AVCS where the pilot supporting C2 communications is located 

• UAS C2 Communications Link Component - communications links, systems, 
and equipment that provide the telecommunications connection between the 
AVCS and the UA 

• UA C2 Communications Equipment Component - systems and equipment 
onboard the UA 

The generic external interfaces to the C2 Communications System include the 

following: 

• UA Pilot in the AVCS - A human-machine interface between the PIC and the 
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C2 communications equipment 

• Onboard Systems Interfaces - Systems onboard the UA that 1) perform actions 
based on communications from the PIC and 2) provide information to the PIC 


3.3 Communications Links 

Figure 3 depicts a notional concept for communications links for HALE UAS. There 
are three links: C2 link, AVCS-ATC link, and UA-ATC link. At any given time, 
from one to all three of these links may be in use. As the figure shows, Line-of-Sight 
(LOS) communications uses direct links, while Beyond Line-of-Sight (BLOS) 
requires additional communications equipment or relays. This document addresses 
the C2 link, while a separate document addresses communications with the ATC. 


Communication 

Satellite 



3.3.1 C2 Link 

The C2 link is the mainstay C2 communications link and supports LOS and BLOS 
communications as needed. The PIC controls the UA from the AVCS by sending 
short commands (messages) to affect the dynamics (such as attitude, altitude, speed) 
of the UA. This link is often referred to as the uplink. The UA sends data to the 
pilot to keep him/her informed of the flight status. This data includes health and 
status of the UA and situation awareness. This communication path is often referred 
to as the downlink. 
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3.3.2 AVCS-ATC and UA-ATC Links 


The AVCS-ATC and UA-ATC links are covered in the HALE ROA ATC 
Communications Step 1 Requirements Document. 

3.3.3 LOS and BLOS Communications 

In the en route phase, there may be no direct LOS path between the HALE UA and 
its AVCS. Thus, C2 communications must support both LOS and BLOS 
configurations. 

Satellite communications (SATCOM) and airborne relay are two feasible means for 
such C2 BLOS communications. Airborne relay, if used, can cover a limited range 
only and thus is often adopted for small footprint UA operation. SATCOM is the 
common solution for use in long haul communications. There are two types of 
SATCOM available today: geostationary orbit (GEO) and low earth orbit (LEO). 
For GEO, the channel can be available through leasing and the network can be 
custom designed. For LEO, only the service is available. That is, service 
subscribers have no way to affect the network optimization if needed. A major issue 
when employing any SATCOM solution is the system latency resulting from the 
propagation delay and the network processing delay. 

3.3.4 Data Links in the NAS 

Although the C2 links are intentionally separated from the ATC communication, this 
HALE UAS C2 communications FRD has been developed to be able to take 
advantage of the NAS Modernization Program to the maximum extent. More 
specifically, the modernized NAS infrastructure is potentially useful for the C2 links. 
For example, increased situation awareness, more accurate weather information, and 
use of satellite technology are of interest to pilot-UA communications. There have 
been several new private link initiatives currently under development to provide the 
C2 capabilities and services in the NAS. They are essentially built on the current 
ATN infrastructure. Appendix D briefly reviews the NAS modernization program 
and Appendix E provides brief information about these existing data links. 


3.4 C2 Information Categories 

The C2 Communications System is used to deliver information exchanges that 
ensure safe, reliable, and effective HALE UA flight operation. The applications for 
these information exchanges are being defined by the Work Packages of Access 5, 
such as Cooperative Collision Avoidance (CCA), Contingency Management (CM), 
Weather, and Human System Interface (HSI). The following types of information 
are exchanged: 
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Command and Control Messages 

These messages are used for flight control and task execution and usually have 
higher priority than other message types. 


Health and Status of UA 

Health and status data provides critical information about the condition of the 
subsystems, sensors, and hardware of the UA. The pilot at the AVCS uses this 
information to maintain full awareness of the ability of the UA to function and to 
diagnose problems. The pilot can then handle potential or actual problems by taking 
preventive measures or corrective actions to ensure continued functioning and thus 
safe flight. 

Situation Awareness Data 

Situation awareness data is the data regarding the operational environment of a UA, 
including data for any aircraft surrounding it. Examples of this data are weather 
conditions, terrain information, and location of surrounding aircraft. The data may 
come from sources such as ADS-B or Traffic Alert and Collision Avoidance System 
(TCAS). In general, the Common Operating Picture (COP) of any airport is 
accessible by the PIC. Use of situation awareness data enhances the “see and avoid” 
capability of HALE UAS. 

Telemetry Data 

Telemetry data provides information regarding the flight characteristics of the UA. 
This data includes items such as flight trajectory, arrival times, altimeter setting, 
altitude, heading, speed, route clearance, and arrival time. The pilot uses this data to 
maintain full awareness of the flight of the UA and to determine the changes needed 
to ensure safe flight. 


Figure 4 illustrates information that is exchanged between the UA and AVCS, using 
the uplink and downlink. The figure provides the pilot viewpoint of C2 functions 
and the information the pilot uses to make decisions, as well as the underlying 
communications capabilities that support the C2 functions. 


PILOT VIEWPOINT 


• Maneuver the UA 

• Change Flight Profile 

• Obtain UA Location and Speed 

• Receive Flight Safety and Emergency Information 

• Transition C2 Between LOS and BLOS 

• Transition C2 from One AVCS to Another 


UPLINK 


LOS/BLOS 


• Command and Control 

• Information Inquity 



AVCS 

Air Vehicle Control Station 


DOWNLINK 

• Situational Awareness 

• Health and Status 

• Telemetry 

COMMUNICATIONS SUPPORT 

• Links for Information Exchanges 

• Message Transfer 

• Procedures and Protocols 

• Security of Links 

• Link Connectivity for C2 Transitions 
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Figure 4. The C2 Communications Links Facilitate C2 Functions 
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4 REQUIREMENTS 


This section defines the minimum functional requirements the HALE UAS C2 
Communications System must meet to be deemed acceptable. Only the C2 link is 
addressed. All the requirements in this section are independent of design or 
implementation. 

The requirements specified in this document for Step 1 are derived from the C2 high 
level functional requirements in the Access 5 FRD. 


4.1 Assumptions 

The Access 5 HALE ROA CONOPS provides a set of assumptions that were used 
for developing the Access 5 FRD. These assumptions plus the following 
assumptions apply to the requirements in this document: 

1. The requirements apply to any HALE UA that plans to fly in the NAS in 
accordance with the guidelines and procedures set forth in Step 1 of the Access 5 
project. 

2. HALE UA take off and land at pre-designated airports. 

3. The requirements apply to the en route phase of HALE UA flight and operations. 
That is, at FL430 and above (Access 5 Step 1). 

4. The HALE UAS C2 Communications System is implemented by the UAS 
manufacturer and operated by a PIC. 

5. Additional requirements will be added as needed for subsequent Access 5 steps. 

4.2 Interfaces 

Interfaces internal to the C2 Communications System are those between the UA pilot 
at the AVCS and on-board UA systems such as the flight control system. 

At the en route phase (Step 1), the UA and AVCS perform all necessary 
communications with each other to ensure safe and reliable HALE UA flight. The 
C2 Communications System facilitates UA pilots to interact and control HALE UA 
comparable to the capabilities of manned aircraft pilots. 
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4.3 C2 Communications System Functional Requirements 


4.3.1 Information Exchanges for UAS Operations 

The C2 Communications System is the conduit for exchanging information between 
the UA and AVCS. The communications are 2-way in order to transport information 
to and from both the UA and the AVCS. Each direction may carry different 
information, such as commands or status data that are used to ensure safety of flight. 
Both directions must work together in an orderly manner to achieve timely delivery 
and preserve message content. 

Since the distance between the UA and the AVCS may exceed LOS, the C2 links 
must be able to handle both LOS and BLOS as needed. The C2 links are typically 
implemented with, but not limited to, modem digital communications via LOS or 
BLOS links. This internal link can be UA manufacturer-specific or any available 
service recommended by the FAA. 


4.3. 1.1 Uplink C2 Communications 

The uplink is the data transmission from the AVCS to the UA. The transmissions 
provide directives and information to the UA, such as commands, status requests, 
and related messages. These transmissions may require LOS or BLOS links, 
depending on the location of the UA relative to the AVCS. 

a. The C2 Communications System shall provide at least one uplink C2 
communication path between the UA and the AVCS. 

b. The C2 Communications System shall use the uplink to transfer information 
from the AVCS to the UA. 

c. The C2 Communications System shall provide uplink communications that are 
LOS and/or BLOS as needed between the UA and AVCS. 


4.3. 1.2 Downlink C2 Communications 

The downlink is the data transmission from the UA to the AVCS. The transmissions 
provide necessary and timely data for the pilot to conduct safe flight operations. The 
data may contain telemetry, situation awareness, health and status, and other data as 
needed. The transmissions may require LOS or BLOS links, depending on the 
location of the UA relative to the AVCS. 
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a. The C2 Communications System shall provide at least one downlink C2 
communication path between the UA and the AVCS. 

b. The C2 Communications System shall use the downlink to transfer information 
from the UA to the AVCS. 

c. The C2 Communications System shall provide downlink communications that 
are LOS and/or BLOS as needed between the UA and AVCS. 


4.3. 1.3 Cohesive and Consistent Uplink and Downlink Operations 

It is critical that messages that are initiated for sending are received within enough 
time to be useful and with their contents preserved. The uplink and downlink 
operations must work together correctly in a timely manner to achieve these goals. 

a. The C2 Communications System shall coordinate the uplink and downlink 
operations to provide orderly message transfer. 

b. The C2 Communications System shall maintain message integrity for both uplink 
and downlink operations. That is, the received message is unaltered from the 
sent message. 

c. The C2 Communications System shall provide a means to manage message 
delivery delays based on priority criteria. 


4.3.2 Communications Procedures and Protocols 

Procedures and protocols are the established steps and functional mechanisms that 
regulate information exchanges between the AVCS and UA. These procedures and 
protocols must provide systematic link access and parameters for data transmission. 
Due to the complexity of the C2 Communications System and the time criticality of 
many communications, it is expected that automated means will be employed for 
procedures and protocols where needed to achieve effective system performance. 


4.3.2. 1 Link Protocols for Accessing Shared Communications 

Protocols must be defined for systematically accessing shared communication 
resources, namely the C2 links, when there are multiple requests to use the resources. 
These protocols typically address contention and congestion in shared resources and 
establish the criticality of different types of messages. These defined behaviors and 
criticality designations are used to support safe flight control. 

a. The C2 Communications System shall provide means to resolve conflicts that 
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occur in shared communications media. Examples of these conflicts are 
contention, congestion, and collisions. 


4.3.2.2 Procedures for Communications Assurance 

Procedures for communications assurance support protection of the C2 system. 
Basic communications assurance functions include authentication and non- 
repudiation of information exchanges. 

a. The C2 Communications System shall provide communication assurance 
procedures as needed prior to, dining, and after information exchanges. 


4.3.2.3 Procedures for Data Transmission 

The C2 links are configured accordingly to ensure that both the AVCS and UA send 
and receive data correctly. Procedures must be defined to set and change the data 
transmission parameters, which include items such as frequency, data rate, 
modulation/coding, antenna usage, and transmit power. 

a. The C2 Communications System shall provide means for data transmissions 
prior to, during, and after flight operations. 

4.3.3 Communications to Control Safe Flight and UA Operations 

Although the pilot and UA are physically separate, it is expected that the UA will 
behave as if the pilot is onboard. Therefore the C2 Communications System is vital 
for the pilot to transmit information that directs UA operations and ensures flight 
safety. When actions are time critical, the UA must receive and act on the most 
important information first. Comparable to onboard pilots in the current NAS, the 
transmitted directives must not interfere with the NAS. 


4.3.3. 1 Situational Awareness and Health and Status of the UA 

Since the UA pilot is offboard the aircraft at all times and “flies” the aircraft from the 
AYCS, the UA must transfer onboard information to the pilot. This information may 
include health and status of the aircraft or its subsystems, as well as in-flight 
situation awareness information from onboard sensors and systems. The particular 
information that platforms transfer is manufacturer-specific. 

a. The C2 Communications System shall exchange situation awareness data. The 
pilot at the AVCS uses this data to conduct safe flight control. 
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b. The C2 Communications System shall exchange UA health and status data. 
Examples of health and status data are fuel remaining and landing gear status. 


c. The C2 Communications System shall exchange telemetry data. Examples of 
telemetry data are flight trajectory, altimeter setting, altitude, heading, speed, and 
route clearance. 


4.3.3.2 C2 Directives to the UA 

Since the UA pilot is offboard the aircraft at all times and “flies” the aircraft from the 
AYCS, the pilot must transfer directives to the UA. These directives may include 
flight commands and requests for data. The particular directives that the pilot issues 
are manufacturer-specific. 

a. The C2 Communications System shall exchange command and control messages. 
These messages include commands, requests, informational messages, and 
related data. 


4.3.3.3 Capability to Prioritize C2 Information Exchanges 

Several different types of messages may be conveyed via the C2 link. Some of the 
messages and information are more critical than others to control safe flight, 
depending on the operational environment and events. It is crucial that the C2 
Communications System transfer higher priority messages before transferring lower 
priority messages. In effect, higher priority messages are transferred with less delay 
than lower priority messages. 

a. The C2 Communications System shall be able to prioritize the C2 information. 

b. In the C2 Communications System, information regarding safety of flight shall 
have the highest priority. 


4.3.3.4 Protection Means to Coexist with Current NAS Systems and Operations 

The link between UA and AVCS (i.e., C2 link) is a new addition to the NAS 
infrastructure and must be compatible with it. Part of this compatibility is that the 
C2 link must not introduce any harmful radio frequency interference (RFI) that 
would compromise the current NAS systems and operations. 

a. The C2 Communications System shall comply with the current NAS RFI 
environmental requirements. 
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4.3.3.5 Ability to Distinguish Each UA 


For flight safety and task success, it is paramount to be able to identify, communicate 
with, and control each UA without any ambiguity. 

a. The C2 Communications System shall be able to distinguish each UA. 


4.3.4 Secure C2 Link 

Security of the C2 link is important to the safety of the UA and other aircraft and 
personnel in the NAS. Only authorized users should be able to access the C2 link to 
perform message transfers to control the UA. The transmissions themselves must 
not be corrupted, changed, or denied, and unauthorized messages must not be 
inserted into the message traffic; to do so could jeopardize safety as well as success 
of the tasks. 


4.3.4. 1 Prevention of Unauthorized Access 

The C2 Communications System must be capable of preventing any unauthorized C2 
of the UA. As a minimum, C2 communications must be authenticated and 
authorized. Access requirements are particularly challenging since the C2 link is 
wireless and continuously moving through space. 

a. The C2 Communications System shall provide safeguards that deny unauthorized 
users the ability to command and control the UA. 


4.3.4.2 Resistance to Jamming or Interference 

The consequence of unplanned loss of link use can be significant to flight safety. A 
major cause of unplanned loss of use is intentional and unintentional jamming or 
interference, such as by deliberate actions or natural effects. The C2 
Communications System must be resistant to jamming and interference. For 
example, the UAS may have communications equipment that is anti-jam or anti- 
interference or procedures could be defined to handle jamming and interference. 
These measures result in enhanced safety. 

a. The C2 Communications System shall have provisions for anti -jamming or anti- 
interference. 


4.3.5 Link Connectivity 


To ensure flight safety, it is ideal to maintain C2 communications at all times. 
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During the course of operations, transitions may occur that could cause a break in C2 
communications. These transitions include those between LOS and BLOS 
communications and between one AVCS and another. During such transitions, the 
goals are to maintain information continuity between the AVCS and UA and to 
minimize any communications dropouts. Additionally, if there is a communications 
dropout during such a transition, it is preferred that the system refrain from 
automatically launching lost link procedures. Rather, the system should be able to 
evaluate the dropout to determine its significance and whether or not it warrants 
triggering lost link procedures. 


4.3.5.1 C2 Communications While Transitioning Between LOS and BLOS 
Operations 

Typically, the UA flies away from LOS and flies to BLOS with respect to the AVCS. 
The C2 Communications System must be capable of providing communications for 
both LOS and BLOS conditions, including the transition between them. Due to 
physical constraints that may exist, such as during transitions between satellites or at 
the edge of a satellite footprint, scheduled and/or predictable link dropouts may be 
acceptable as long as there are contingency plans in place. 

a. The C2 Communications System shall maintain the C2 link between the UA and 
the AVCS at all flight phases, including transition between LOS and BLOS. 

b. The C2 Communications System shall allow scheduled and/or predictable C2 
dropouts that result from physical constraints. These dropouts do not trigger lost 
link procedures unless the dropout time exceeds an acceptable threshold. 
Excessive dropout events are managed by the Contingency Management 
function. 


4.3.5.2 C2 Communications While Transitioning Between Different AVCS 
Stations 

During the course of UA flight, it is possible that more than one AVCS is employed, 
though there is no requirement to have more than one AVCS. The C2 
Communications System must be capable of providing communications between the 
UA and the AVCS in control, including the transition from one AVCS to another. 

a. The C2 Communications System shall maintain the C2 link between the UA and 
the AVCS at all flight phases, including possible handover from one AVCS to 
another. 

b. When more than one AVCS is deployed, the C2 Communications System shall 
provide a C2 link between each AVCS. 
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5 Verification / Validation 


5. 1 Responsibility for Verification 

The UA manufacturer or UA provider is responsible for all requirement compliance 
test and verification. 


5.2 Test and Evaluation Guidelines 

The following list provides guidelines for verifying the requirements in this 

document. These guidelines provide items to consider when defining verification 

tests and evaluation criteria. 

• The verification tests should use representative message traffic that is close to 
real message traffic, to ensure meaningful results. Factors to include in test 
message traffic are data fidelity and traffic load during nominal and peak 
conditions. 

• The verification tests should use a sufficient quantity of data, to ensure 
meaningful results. 

• The verification tests should be conducted using pre-collected data whenever 
possible, to reduce cost and schedule. 

• The verification tests should be conducted using simulations and other subsystem 
tests rather than flight tests wherever possible, to reduce cost and schedule. 

• The verification results should be evaluated for compliance with individual 
requirements as well as for meeting overall program goals, including safe 
operation of UA and seamless integration with the NAS. 


5.3 Methods of Verification 

The following verification methods are used to verify compliance of individual 
requirements identified in this document. The five verification methods, listed in 
increasing order of complexity, are defined as: 

a. Inspection : A non-destructive static-state critical examination of the hardware, 
technical data, and documentation. Special laboratory appliances, procedures, or 
services are not used. 

b. Analysis : Comparison of the design against known scientific and technical 
principles, procedures, and practices to estimate the capability of the proposed design 
to meet the mission and system requirements. This method may also include 
mathematical evaluation and review of the design and representative data. 
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c. Simulation : Representation of the end item with a similar or simpler software 
model that is an abstraction of the end item, is more easily manipulated, or uses an 
alternate platform. This method uses standalone software that processes 
representative data for representative scenarios. The software represents the features 
and internal processing of the end item, while the execution results provide estimates 
of the true interactions, behaviors, and performance of the system. 

d. Test : Performance is measured during or after systematic and controlled 

application of functional and/or environmental stimuli. Quantitative measurements 
are analyzed to determine degree of compliance. The process uses laboratory 
equipment, procedures, items, and services and includes hardware-in-the-loop 
testing. 

e. Demonstration : Qualitative determination of properties of the end item, including 
the use of technical data and documentation. The items being verified are observed, 
but not quantitatively measured in a dynamic state. This method focuses on flight 
testing. 


5.4 Verification Matrix 


Table 1 is the verification matrix for the requirements defined in this document. 


Table 1. Verification Matrix 


Identifier 

Requirement 

Verification 

Method 

4.3.1. I.a 

The C2 Communications System shall provide at least one uplink C2 
communication path between the UA and the AVCS. 

Inspection 

4.3.1. I.b 

The C2 Communications System shall use the uplink to transfer 
information from the AVCS to the UA. 

Simulation 

4.3.1.1.C 

The C2 link shall provide uplink communications that are LOS and/or 
BLOS as needed between the UA and AVCS. 

Simulation 

4.3.1.2.a 

The C2 Communications System shall provide at least one downlink 
C2 communication path between the UA and the AVCS. 

Inspection 

4.3. 1.2. b 

The C2 Communications System shall use the downlink to transfer 
information from the UA to the AVCS. 

Simulation 

4.3.1.2.C 

The C2 link shall provide downlink communications that are LOS 
and/or BLOS as needed between the UA and AVCS. 

Simulation 

4.3.1.3.a 

The C2 Communications System shall coordinate the uplink and 
downlink operations to provide orderly message transfer. 

Simulation 

4.3. 1. 3. b 

The C2 Communications System shall maintain message integrity for 
both uplink and downlink operations. 

Simulation 

4.3.1.3.C 

The C2 Communications System shall provide a means to manage 
message delivery delays based on priority criteria. 

Simulation 

4.3.2. I.a 

The C2 Communications System shall provide means to resolve 
conflicts that occur in shared communications media. 

Analysis 

4.3. 2.2. a 

The C2 Communications System shall provide communication 
assurance procedures as needed prior to, during, and after 
information exchanges. 

Analysis 
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4.3.2.3.a 

The C2 Communications System shall provide means for data 
transmissions prior to, during, and after flight operations. 

Demo 

4.3. 3.1 .a 

The C2 Communications System shall exchange situation awareness 
data. 

Demo 

4.3.3. 1.b 

The C2 Communications System shall exchange UA health and status 
data. 

Demo 

4.3. 3.1 .c 

The C2 Communications System shall exchange telemetry data. 

Demo 

4.3.3.2.a 

The C2 Communications System shall exchange command and 
control messages. 

Demo 

4.3.3.3.a 

The C2 Communications System shall be able to prioritize the C2 
information. 

Analysis 

4.3. 3.3. b 

In the C2 Communications System, information regarding safety of 
flight shall have the highest priority. 

Demo 

4.3. 3.4. a 

The C2 Communications System shall comply with the current NAS 
RFI environmental requirements. 

Analysis 

4.3.3.5.a 

The C2 Communications System shall be able to distinguish each UA. 

Analysis 

4.3.4. 1. a 

The C2 Communications System shall provide safeguards that deny 
unauthorized users the ability to command and control the UA. 

Analysis 

4.3.4.2.a 

The C2 Communications System shall have protection provisions for 
anti-jamming or anti-interference. 

Analysis 

4.3.5. 1. a 

The C2 Communications System shall maintain the C2 link between 
the UA and the AVCS at all flight phases, including transition between 
LOS and BLOS. 

Demo 

4.3. 5.1 .b 

The C2 Communications System shall allow scheduled and/or 
predictable C2 dropouts that result from physical constraints. 

Demo 

4.3.5.2.a 

The C2 Communications System shall maintain the C2 link between 
the UA and the AVCS at all flight phases, including possible handover 
from one AVCS to another. 

Demo 

4.3. 5.2. b 

When more than one AVCS is deployed, the C2 Communications 
System shall provide a C2 link between each AVCS. 

Demo 
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Appendices 


Appendix A - Acronym List 

This appendix defines acronyms used in this document. 

ACARS Aircraft Communications and Reporting System 

ADS Automatic Dependent Surveillance 

ADS-B Automatic Dependent Surveillance - Broadcast 

AMSS Aeronautical Mobile Satellite Service 

ARTCC Air Route Traffic Control Center 

ATC Air Traffic Control 

ATM Air Traffic Management 

ATN Aeronautical Telecommunications Network 

AVCS Air Vehicle Control Station 

BER Bit Error Rate 

BLOS Beyond Line of Sight 

CCA Cooperative Collision Avoidance 

CDM Collaborative Decision-Making 

CM Contingency Management 

CNS/ATM Communications, Navigation, Surveillance / Air Traffic Management 

CoA Certificate of Authorization 

CONOPS Concept of Operations 

COP Common Operating Picture 

CPDLC Controller-Pilot Data Link Communications 

CSMA Carrier Sense Multiple Access 

C2 Command and Control 

DSR Display System Replacement 

D8PSK Differentially Encoded 8-Phase Shift Keying 

EAP Extensible Authentication Protocol 

ELOS Equivalent Level of Safety 

FAA Federal Aviation Administration 

FANS Future Air Navigation System 

FAR Federal Aviation Regulation 

FDMA Frequency Division Multiple Access 

FL Flight Level 

FL180 Flight Level 180 (18,000 feet) 

FL430 Flight Level 430 (43,000 feet) 

FRD Functional Requirements Document 

GEO Geostationary Orbit 

GPS Global Positioning System 

HALE High Altitude, Long Endurance 

HOCSR Host/Oceanic Computer System Replacement 

HSI Human System Interface 
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IC2DL Interoperable C2 Data Link 

ICAO International Civil Aviation Organization 

IEEE Institute of Electrical and Electronics Engineers 

ITWS Integrated Terminal Weather System 

LAAS Local Area Augmentation System 

LEO Low Earth Orbit 

LOS Line of Sight 

MAC Medium Access Control 

MASPS Minimum Aviation System Performance Standards 

MSL Mean Sea Level 

MTBF Mean Time Between Failures 

MTTR Mean Time to Repair 

NAS National Airspace System 

NASA National Aeronautics and Space Administration 

NEXCOM Next Generation Air/Ground Communications 

NIST National Institute of Standard and Technology 

OSI Open System Interconnect 

pFAST Passive Final Approach Spacing Tool 

PIC Pilot-in-Command 

PK Public Key 

RFI Radio Frequency Interference 

ROA Remotely Operated Aircraft 

SATCOM Satellite Communications 

SMA Surface Movement Advisor 

SSR Secondary Surveillance Radar 

STARS Standard Terminal Automation Replacement System 

TCAS Traffic Alert and Collision Avoidance System 

TDMA Time Division Multiple Access 

TKIP Temporal Key Integrity Protocol 

TMA Traffic Management Advisor 

UA Unmanned Aircraft 

UAS Unmanned Aircraft Systems 

UHF Ultra High Frequency 

URET/CCLD User Request Evaluation Tool/Core Capability Limited Deployment 

VDL YHF Data Link 

VHF Very High Frequency 

WAAS Wide Area Augmentation System 

WARP Weather and Radar Processor 

WPA Wi-Fi Protected Access 
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Appendix B - Definitions 


This appendix defines terms used in this document. 

Aeronautical Telecommunications Network (ATN) - A communications 
network conceived by ICAO Future Air Navigation System (FANS) to support 
the future Communications, Navigation, Surveillance / Air Traffic Management 
(CNS/ATM) concept. 

Air Route Traffic Control Center (ARTCC) - Provides Air Traffic Service to 
aircraft operating on IFR flight plans within the controlled airspace, and 
principally during the en route phase of flight. It is the largest component of the 
NAS and each ARTCC covers thousands of square miles encompassing all or 
part of several states. 

Air Vehicle Control Station (AVCS) - A site configured to allow a pilot in 
command of a UA to operate and monitor all UA operations conducted under his 
or her authority. 

Beyond Line of Sight (BLOS) - The condition where the straight line path 
between any pair of communication nodes are obstructed. 

Command and Control Link - Two-way data link between the UA and the UA 
pilot-in-command at the AVCS. This link is used for flight control and all 
necessary information exchange for the purpose of safe flight. The link may be 
LOS or BLOS. 

En Route - A phase of flight in which the pilot receives instructions regarding 
the altitude and heading to maintain, as well as the radio frequency to tune. This 
portion of the flight can be as short as a few minutes or as long as many hours. 

Equivalent Level of Safety - An evaluation, often subjective, of a system and/or 
operation to determine the acceptable risk to people and property. 

High Altitude Long Endurance (HALE) - Flight and operations at an altitude 
of 40,000-foot mean sea level (MSL) or higher with sufficient cruise capability to 
transit the NAS. 

Line of Sight (LOS) - The condition where the path between any pair of 
communication nodes form an unobstructed straight line. 

Pilot-in-Command (PIC) - As defined in 14 CFR Part 1, a person who: 

1 . Has final authority and responsibility for the operation and safety of the flight; 

2. Has been designated as pilot in command before or during the flight; and 
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3. Holds the appropriate category, class, and type rating, if appropriate, for the 
conduct of the flight. 

Remotely Operated Aircraft (ROA) - An aircraft that is operated from a 
remote location by an operator that issues command and control instructions to 
the aircraft, which are executed near real-time by an onboard autonomous flight 
management control system. 

ROA Airport - An airport that is capable of handling ROA operations. 

Unmanned Aircraft (UA) - An aircraft in which the pilot-in-command is 
physically located outside of the UA. ROA are a subset of UA. 

UA Airport - An airport that is capable of handling UA operations. 
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Appendix C - C2 Communications Requirements Excerpted from 
Access 5 FRD 


The major revision of the Access 5 FRD has been carried out during the 
development of this C2 Communications FRD. As a result, there have been 
discussions taking place between these two development processes. 


Figure C-l depicts the high-level functional partition defined in the latest version 
of the Access 5 FRD. C2 is a cross cutting function to interact with or facilitate 
all the other UAS functions that include “communicate.” Command, Control, 
and Communicate within the UAS are the subjects of this C2 Communications 
FRD. 



Figure C-1. UAS Functional Partition 


The lower level functional requirements of the C2 are further decomposed by this 
work package and concurred with the Access 5 FRD process. The headings of 
these functions are shown in Figure C-2. The detailed functional descriptions 
and requirements are the main part of this C2 Communications FRD. 
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Figure C-2. Command / Control Cross-Cutting Functions 


The following table is the excerption of the requirements from the Access 5 FRD 
that are related to C2 communications. 


Table C-1. C2 Communications Requirements Excerpted from the Access 5 
Functional Requirements Document (FRD) 


Section Number 

Description 

5.3.1. 1 

Transmit information within the UAS. 

5.3. 1.2 

Receive information within the UAS. 

5.5.1. 1 

Exchange information. 

5.5. 1.2 

Control UA flight operations. 

5.5. 1.3 

Prevent unauthorized operation of the UAS. 

5.5. 1.4 

Provide link connectivity. 
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Appendix D - The NAS Modernization Overview 


This appendix presents the NAS modernization overview and its capabilities. It 
is anticipated that the heavily invested NAS infrastructure can be utilized as 
appropriate. In particular, some of the currently deployed ATN capabilities and 
services are also applicable to the command and control (C2) communications 
li nk for Unmanned Aircraft Systems (UAS) with technical enhancements or 
capability upgrades. For example, increased situation awareness, more accurate 
weather information, and use of satellite technology are all of interest to C2 
communications in a UAS. 

The following information is excerpted from the FAA website. 

The FAA has been executing the NAS Modernization Program since 1998. It is 
a three-phase fifteen-year program that involves providing new systems to 
enhance capabilities and services for users: 

• Clear, less congested air/ground communications using digital technology 

• Accurate navigation and landing services to more airports using satellite 
technology 

• Expanded surveillance coverage of airspace and airport surfaces 

• Increased air-to-air situation awareness for pilots 

• More efficient sequencing of arriving and departing aircraft through 
improved air traffic control decision support tools 

• Accurate and timely weather data to controllers and pilots 

• Sharing of real-time information between users and providers 

• Increased ability of users to fly more direct routes 

Modernization also includes making the critical infrastructure of air traffic 
control services easier and more cost-effective to operate and maintain. Critical 
infrastructure includes: 

• Communications, navigation/landing, and radar surveillance systems 

• Weather detection and reporting equipment 

• Air traffic control computers and displays for controllers 

• Power generation and backup systems 

• Air traffic control facilities sustainment 

In what follows, we provide a brief summary of key NAS sy stems/ capabilities 
and their architectural improvements. 

Communications 


Aviation communications systems will be upgraded, integrating systems into a 
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seamless network using digital technology for voice and data. During the 
transition, the FAA will continue to support analog voice communications. 
Specific improvements include: 

• Controller-pilot data link communications (CPDLC), which introduces 
electronic data exchange between controllers and the cockpit and reduces 
voice-channel congestion. 

• Digital voice communications via new digital radios provided by the next 
generation air/ground communications program, which improves spectrum 
utilization. Ultra-high frequency (UHF) analog radios will be retained for 
Department of Defense users. Radios operating in the analog mode will be 
retained in many low-density areas for general aviation users. 

Navigation 

Over the next 10 years, the navigation system is expected to use satellites 
augmented by ground monitoring stations to provide navigation signal coverage 
throughout the NAS. Satellite-based navigation will support direct routes and 
help users meet their schedules with more predictability. Reliance on ground- 
based navigation aids is expected to decline as satellite navigation provides 
equivalent levels of service. 

The transition to satellite-based navigation consists of: 

• Use of the global positioning system (GPS) as a supplemental system for 
en route navigation and non-precision approaches. 

• Deployment of the wide area augmentation system (WAAS) to augment 
GPS for primary means en route navigation and precision approaches. 
WAAS will be deployed in stages by adding ground reference stations, 
with operational capability improving in each stage. 

• Deployment of a local area augmentation system (LAAS) to augment GPS 
for precision approaches in low visibility conditions. 

Surveillance 


Surveillance in the future NAS will provide increased coverage in non-radar 
areas and include aircraft-to-aircraft capabilities for greater situation awareness. 
The NAS Architecture calls for gradual transition from current radar systems to 
digital radar and automatic dependent surveillance (ADS). 

Air-to-air ADS-Broadcast (ADS-B), a new avionics surveillance package, is 
being developed to include a cockpit display of traffic information feature that 
shows the position of all ADS-B-equipped aircraft to enhance the pilot's 
awareness of the surrounding environment. Later, a compatible ground system 
will be deployed to provide the same ADS-B surveillance information to 
controllers as seen by pilots. 
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Aviation Weather 


The NAS Architecture contains improved ways to collect, process, transmit, and 
display weather information to users and providers, during flight planning and in 
flight. The goal is to give NAS providers and users depictions of weather 
information and provide more weather data in the cockpit to enhance common 
situation awareness. New features include: 

• Integrated terminal weather system (ITWS), which provides near-term (0- 
30 minutes) prediction of significant weather in the terminal area. It 
generates products, including wind shear and microburst predictions, 
storm cell hazards, lightning information, and terminal area winds. ITWS 
integrates data from radar, weather sensors, National Weather Service 
models, and automated aircraft reports. 

• Weather and radar processor (WARP), which receives and processes real- 
time weather data from multiple sources for the en route environment. It 
prepares national and regional weather mosaics and mosaics for the 
controller's displays and provides grid forecast data from the National 
Weather Service to other NAS automation systems. 

• Delivery of weather and other flight information services to the cockpit 
via a private service provider primarily targeted to supporting general 
aviation users. 

Avionics 


Avionics will evolve to take advantage of new communications, navigation, and 
surveillance-related technologies in the NAS Architecture, including: 

• GPS receivers that enable aircraft to navigate via direct routes and fly 
precision instrument approaches to virtually any runway. Combining GPS 
with cockpit electronic terrain maps and ground-proximity warning 
systems can help pilots avoid controlled flight into terrain. 

• New multi-mode digital radios for voice and data communications among 
pilots, controllers, and various ground facilities. 

• Digital communications technology that increases available voice channel 
capacity and provides a data link that enables instructions, flight 
information services, and graphical weather data to be sent directly to the 
cockpit. 

• ADS-B that transmits GPS-based position, velocity, and intent information 
to ground stations and other aircraft. 

• Multi-functional cockpit displays to present information that improves 
situation awareness. 

• Traffic alert and collision avoidance system (TCAS), which provides 
pilots with advisory information to prevent mid-air collisions with other 


33 

The following document was prepared by a collaborative team through the noted work package. This was a 

funded effort under the Access 5 Project. 



transponder-equipped aircraft, will be enhanced and remain the primary 
safety system to prevent air-to-air collisions. 


Free Flight Phase 1 

New tools that give controllers, planners, and service operators more complete 
information about air traffic control and flight operations comprise a large part of 
the NAS Architecture's near-term plan. Some of these tools are embodied in a 
program called Free Flight Phase 1 Select Capability/Limited Deployment. The 
Free Flight Phase 1 tools are: 

• User request evaluation tool/core capability limited deployment (URET 
CCLD) - an automated tool that assists en route controllers in identifying 
conflicts up to 20 minutes in advance of their occurrence. 

• Traffic management advisor (TMA) single center - an automated tool that 
assists en route radar controllers with sequencing aircraft to terminal areas. 

• Passive final approach spacing tool (pFAST) - an automated tool designed 
to work in conjunction with TMA to help controllers assign runways and 
sequence aircraft according to user preferences and airport capacity. 

• Collaborative decision-making (CDM) - a real-time exchange of flight 
plan and system constraints data between the FAA and airline operations 
centers in order to work collaboratively to better manage NAS traffic. 

• Surface movement advisor (SMA) - a system that provides information 
sharing to airline and airport personnel who plan and manage the sequence 
of taxi out and plan for arrivals in the ramp and gate areas at larger 
airports. 

Automation Infrastructure 


Free Flight Phase 1 tools and other future tools depend on infrastructure 
improvements already underway, such as the following, to operate: 

• Display System Replacement (DSR) provides new controller workstations 
and a network infrastructure for the air route traffic control centers 
(ARTCC). DSR has the capability to show weather data from the next 
generation weather radar. 

• Standard Terminal Automation Replacement System (STARS) is the new 
terminal workstation that will interface with the new sequencing and 
spacing tools and the advanced communications, navigation, surveillance, 
and weather systems. 

• Host/Oceanic Computer System Replacement (HOCSR) replaces the host 
and oceanic processors and peripherals at the ARTCCs to solve immediate 
hardware supportability problems. 

The NAS Architecture also plans for an integrated NAS information service for 
users and providers to receive and share common data and jointly make 
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operational planning decisions. This information service includes a system-wide 
information network, use of standardized data formats, and interoperability 
across applications. 
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Appendix E - Current ATN Data Links 


This appendix introduces the current ATN data links available for use in the 
aviation industry, recommended by ICAO and RTCA. 

Mode S 


The Mode S Secondary Surveillance Radar (SSR) System is a fully digital 
surveillance system that provides both general (broadcast) surveillance and 
specific (addressed to a given aircraft) surveillance. This digital surveillance 
system has a data carrying capability that is utilized for the ATN. Mode S has 
been under development for a long time and it appears that Mode S will be 
introduced for surveillance, with equipment programs for Mode S in place in 
both Europe and North America. Nevertheless, there seems to be little support at 
the moment for the use of Mode S data link, perhaps due to the development of 
VHF Data Link (VDL). In the long run, Mode S is the only currently available 
air/ground technology that offers the potential for megabit data transfer. 

VHF Data Link £VDL) 

Mode 1 : is a low risk but low capability option (600 bps is the channel rate 
shared amongst all using aircraft). It uses existing Aircraft 
Communications and Reporting System (ACARS) radio technology. The 
access scheme is carrier sense multiple access (CSMA) that is simple but 
gives rise to non-deterministic channel access times. Mode 1 is unlikely 
to be used operationally. 

Mode 2 : is an onwards development of Mode 1, uses the same frequency 
band with differentially encoded 8-phase shift keying (D8PSK) to give a 
channel rate of 31.5 kbps. However, CSMA is still used as the channel 
access procedure that will still result into exponentially increasing delay 
time in a high load system. There are thus question marks over the use of 
VDL Mode 2 for operational use. 

Mode 3 : is a significant improvement over Mode 2 using Time Division 
Multiple Access (TDMA) scheme for channel access, while operating the 
same channel rate as Mode 2. It also supports voice communications in 
the same channel, in spite of a significant technical risk. The use of 
TDMA permits a deterministic transit delay to be offered and bandwidth 
utilization is much improved over Mode 2. 

Mode 4 : uses the same frequency band as the other VDL modes and 
carries 31.5 kbps data capacity using D8PSK. It also uses TDMA. 
However, while Mode 3 replies on a ground station to provide the 
channel-synchronizing signal for TDMA, Mode 4 is self-synchronizing 
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and hence permits air-air communication in the absence of ground 
stations. The data link procedures provide a simple acknowledged 
connectionless service. This is the most efficient data link service for 
ATN use. The channel reservation protocol Mode 4 requires position 
information that leads to support for ADS-B readily. 

Aeronautical Mobile Satellite Service (AMSS) 

The AMSS uses the INMARSAT Geostationary Satellite to provide a global 
communications service to aircraft (albeit with coverage limitations near the 
pole). A dedicated set of frequencies is made available to aeronautical mobiles 
and these are broken down by Frequency Division Multiple Access (FDMA) into 
a number of discrete channels. There are four types of channel that form a 
network service. They are TDMA ground to air, slotted Aloha air to ground, 
TDMA air to ground, and bi-directional channels. Both 2.4 Kbps service and a 
10.5 Kbps service are available, but they are shared by all aircraft 
communicating via the same satellite. The communication service provided to 
users is derived from ITU-T X.25. 
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Appendix F - C2 Communications System Performance 
Guidelines 


F.1 C2 Communications System Performance Guidelines 

This appendix provides performance guidelines for the functional requirements 
outlined in this document. The purpose of the performance guidelines is to 
provide some measurable performance indicators in connection with the UA 
control capability. Where quantitative values are used, they should be considered 
a starting point for further analysis. The ultimate goal of the performance 
guidelines is to be able to achieve safe and reliable HALE UA operations in the 
NAS. 


F.1 .1 Availability 

High availability of the C2 Communications System is essential to successful UA 
flight and routine operation in the NAS. Availability applies to the bandwidth 
for transmission, the coverage of satellite footprints (if used), the operating 
frequency, the available relayed station (when adopted), and the equipment. 

F.1. 1.1 Availability of C2 Links 

To maintain the equivalent level of safety (ELOS) as manned aircraft, the C2 link 
must be available for communications regarding safe separation and control of 
UA. The availability of the C2 link can be characterized by the severity of the 
impact of losing the C2 link, as defined in NAS-SR-1000. That is, C2 link 
availability supports the ability of the NAS to exercise safe separation and 
control over the UA. When the C2 link is not available, the UA cannot receive 
directives from the AYCS. If the UA has onboard capabilities for safe separation 
and control, the impact of losing the C2 link is less severe. Nonetheless, the 
AVCS may have a need to dispatch overriding directives, thus increasing the 
severity of a lost C2 link. Therefore, the C2 link should be available between 
the critical and essential levels. 


F.1. 1.2 Available Channel Capacity or Bandwidth 

a. The C2 Communications System should provide sufficient channel capacity 
(also known as bandwidth in general) for all the data required for safe and 
reliable UA operations. 

b. The C2 Communications System should provide channel capacity of 64 Kbps 
(threshold) or greater in which at least 2.4 Kbps capacity (threshold) should be 
reserved for flight control. 
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Note: The channel capacity recommended here considers all support discussed 
in this document that include CCA, CM, HSI functions, situation awareness, and 
potential redundant links, etc. This capacity is best supported by multiple 
physical links. The same order of magnitude of the capability has been employed 
by current Unmanned Aircraft (UA). 

F.l.1.3 Operating Frequency 

The operating frequencies of the C2 link must comply with or be approved by 
FCC and all other related government authorities prior to certification or 
approval. 

F.l.1.4 Satellite Footprint 

When SATCOM is employed, the satellite footprint must provide sufficient 
coverage for the flight plan to ensure required availability of the C2 link for safe 
and reliable fights. 


F.1.2 Reliability 

The C2 communication equipment will be in use continuously and the operating 
environment such as temperature may vary as a function of time. High reliability 
equipment is strongly desirable. Reliability refers to the number of failures in a 
given time period. Mean time between failures (MTBF) is a standard reliability 
measure widely used in the industry. The MTBF given in this section specifies 
the minimum and achievable system reliability for the C2 communications 
equipment. The MTBF is the inverse of the failure rate (failures per million 
hours) as defined in MIL-HDBK-2 1 7F. 

Mean time to repair (MTTR) is another measure related to availability/reliability. 
It conventionally refers to time for a person to make a repair. When a failure 
occurs onboard an UA, MTTR does not apply, since a person is not onboard to 
make repairs. As a guideline to promote communications equipment 
availability/reliability, the UA manufacturer could consider providing redundant 
systems. The formal definition of MTTR is contained in NAS-SS-1000 and 
MIL-HDBK-472. 

In general, the equipment vendors provide MTBF data. The UA integrator will 
predict the overall system reliability from the MTBFs of various subsystems or 
equipment. 

a. The C2 Communications System equipment should provide the following 
MTBF performance: 8,760 hours (threshold) and 26,286 hours (objective). 
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Note: The suggested MTBF hours follow those required by the CPDLC 
equipment as a guideline. The reference is used to account for the commercially 
achievable hardware feasibility instead of for the CPDLC performance. 


F.1.3 Link Performance 

Although there are some known performance measures such as bit error rate 
(BER) for communications links discussed in the literature, we are also interested 
in other less discussed measures. These include the rate of successful message 
transfer and how fast the message can be delivered to the intended recipient, that 
is, the end-to-end message transfer delay. 

BER is a good integrity indicator for equipment but cannot fully characterize the 
end-to-end system performance, which involves the design of message length 
and the network topology selected. The performance measures are usually 
represented in a statistical sense due to the stochastic nature of communication 
channels. 

F. 1.3.1 Signal Integrity 

The BER and Message Error Rate ensure the minimum system integrity. 

a. The BER in C2 equipment should be no more than one erroneous bit in one 
million (10' 6 ) in all operating conditions. 

b. The C2 Communications System should ensure that no more than one control 
message in one billion (10 9 ) is falsely interpreted. 

Note: These performance guidelines are common performance levels offered by 
communication equipment vendors. 
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F. 1.3.2 End-to-End Message Transfer Delay 


The end-to-end message transfer delay measures the time to deliver a message 
from the sender to the receiver, once the message is directed to send. This delay 
includes the time to pass through communications equipment at the UA and 
AVCS, propagation delay, and any network processing delay that has incurred. 
The performance depends on the type of equipment used and the design of the 
communications system. The network incurred delay depends on which network 
is used. It is often a system design issue and hence beyond the scope of this 
document. The propagation delay is a physical issue that we cannot change. But 
it can be affected by the system design depending on which solution is used. 
Hence, it is also beyond the scope of this document. The equipment delay ranges 
from 20 ms to 50 ms that is achievable. As a guideline, the end-to-end message 
transfer delay must be short enough to allow the UA and/or UA operator to be 
responsive to directives and safety issues, while allowing the UA and UA 
operator to function without becoming overloaded. 


F.1.4 Security 

a. The C2 Communications System should implement a protection scheme to 
prevent any hijack or any security incident that may lead to loss of control of 
the UA. That is, security protection should be provided to permit the pilot and 
UA to authenticate the source of the message, and validate that the message 
was not changed during transmission. In general, the issues to be addressed 
include the following as a minimum: 

1 . Message Authentication 

2. Anti-jam or anti-interference (intentionally and un-intentionally) 

3. Key Management 


b. When a public network service such as the ATN of ICAO is employed for C2, 
the standards in Table F-l must be complied with. The source of these 
standards is ICAO 9705, Ed. 3, Sub-volume 8. 


Table F-1. Security Standards for C2 Communications 


Security Mechanisms 

Algorithm Standard 

Message Authentication 

HMAC-SHA-1 RFC 2104 

Encryption 

AES FIPS 197 

Key Agreement 

ECDH ANSI X9.63 

Public Key (PK) certificate 

ITU-T X.509 


c. When a closed or private network is employed, the standards in Table F-l 
should be the threshold performance for the security measure. The IEEE 
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Standard 802.1 li is highly recommended for this use. The latest technology 
Wi-Fi Protected Access (WPA) has been developed in this standard. It 
addresses Wi-Fi security with a strong new encryption algorithm, known as 
Temporal Key Integrity Protocol (TKIP), as well as user authentication. The 
latter employs the 802. IX technology known as Extensible Authentication 
Protocol (EAP). When properly installed, it provides a high level of assurance 
that user data will remain protected and that only authorized users may access 
the network. It can protect against the most targeted hacker attacks known in 
the industry. The features of the WPA are summarized as follows for 
performance comparison: 

• 128-bit keys 

• Dynamic session keys: per user, per session, per packet keys 

• Automatic distribution of keys 

• Strong user authentication, utilizing 802. IX and EAP 

• Built-in Message Integrity Check to prevent hackers 

The industry standards are called out here to ensure traceable performance 
measures for requirements containing additional details. That is, any numerical 
performance parameters can be found in the respective standard. 


F.1.5 Safety 


a. The C2 Communications System should be designed to avoid any single point 
of failure. 


F.1.6 Environmental Conditions 

a. The C2 Communications System equipment must be operable at or above 
FL430 for the en route phase. 
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Appendix G - Methodology 


The overall methodology used to develop this document is a consensus approach 
to progressively develop the requirements. This document is the result of many 
contributions from a team of UA industry leaders and draws on a number of 
document sources and UA activities. As shown in Figure G-l, it is developed 
based on NASA Access 5 project documents, FAA Regulations and Orders, and 
recommended standards and practices by ICAO and FAA-sponsored RTCA. 
Once the requirements are developed, a matrix is defined to establish the 
verification method for each requirement. 


NASA Access 5 CONOPS and FRD 

Research on Industry -Wide UA Operations 
FAA Regulations and Orders 

RTCA / ICAO Standards & Practices 


Knowledge Base : 

UA C2 and Data Links 
SATCOM (TDRSS, IRIDIUM, 
IMARSAT, etc.) 

VSAT Telephony 
MILSTAR 

IEEE Standard 802.11 
Communications / Control Theory 
C4ISR Architecture Framework 



Figure G-1 . Methodology to Develop C2 Communications Requirements 
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Appendix H - Technical Performance Comparisons 

This appendix contains technical discussions of the performance guidelines for 
C2 Communications as compared to the open literature. UAS are an emerging 
industry and the intent is to keep up with ongoing development of requirements 
and standards. However, each standard development body has its own charter 
and thus the depth of the coverage may vary from one to another. As a result, the 
goal is to understand and discuss the comparisons at the high-level system and 
functional levels. Any design-specific discussions are for illustration only. 
Three standards are on our radar screen: 

o RTCA SC-203 
o ASTM International 
o STANAG 4660: IC2DL 

RTCA SC-203 

RTCA develops recommendations to the FAA for communications, navigation, 
surveillance, and air traffic management system issues. Special Committee 203 
(SC-203) is developing standards for UAS to operate in the NAS. This special 
committee formed much later than Access 5. However, they have been meeting 
more frequently. Due to the charter of the committee there have been significant 
participation from various levels of the government agencies. RTCA SC-203 
began with one working group (WG1) divided into three subgroups: Document 
Integration, Operations, and Systems. Two additional working groups are being 
established at the fifth plenary meeting in January 2006. They are Command, 
Control, Communications (C3) and See and Avoid (S&A), named WG2 and 
WG3, respectively. The committee has outlined several UAS MASPS 
documents to be published within a year or so. At the time of this writing, there 
is no performance-related document ready for review. Many participants in SC- 
203 are contributors from Access 5. Some technical framework and subjects of 
interest occurring in this committee have been addressed or considered in the 
Access 5 documents. For example, C3 and S&A have been two active work 
packages in Access 5. 

ASTM International 

The organization, originally known as American Society for Testing and 
Materials, was founded over a century ago. In November 2004 this standard 
forum decided to develop standards for use by the UAV industry. One of them is 
“Standard Specification for Design and Performance of an Unmanned Aerial 
Vehicle (UAV) Data Link System.” This specification includes requirements to 
provide radio frequency (RF) links capable of transmitting data for command and 
control of the air vehicle, payload data and other data between the air vehicle and 
control station. This is a working activity and no document is available for 
review at the time of this writing. 
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STANAG 4660: IC2DL 

The Interoperable C2 Data Link (IC2DL) is the low rate data link standard being 
prepared by the NATO STANAG 4660 working group for the UAV industry 
worldwide. The latest version is 1.2 dated on January 6, 2006 yet it is still a 
working draft. Although it exceeds the scope of the Access 5 program, because 
it addresses waveform and OSI layer specific requirements, the high level 
performance requirement is deemed useful information for cross referencing 
purposes. The following performance requirement table (Mode A) is copied 
from Table B-l of STANAG 4660 to facilitate the comparison discussions that 
follow. 


Table H.1 Detailed Performance Requirements 
From IC2DL Draft vl.2 (page B-9) 


Parameter 

Mode A Requirement 

Remarks 

Bit Error rate (BER) 

icr 8 

1 

Availability 

System Dependent 

2 

Environmental Conditions 

System Dependent 

3 

Frequency 

2.3 -2.4 GHz 1 

4 

Waveform Inter-node Range 

0.001 - 1000 NM 

5 

Date rate 

Variable, but suggested 
typical network data rate 
300 Kbps 

6 

Encryption 

External 

7 

LPI/LPD 

Yes, 10log(BW ratio) 

8 

Latency 

Launch and Recovery 
Sensor 

50-100 ms 
200 ms 

9 

Update Rate 
Launch and Recovery 
Sensor C2 

20 - 25 Hz 
5- 10 Hz 

5 

Polarization 

Vertical 

5 

Communication Protocol 
Ground data terminal (GDT) 
Air data terminal (ADT) 
Digital Voice/ATC 

IP/UDP 2 

TBD 

TBD 

10 

Multiple Access Communication 

TDMA 

5 

External Timing Source (if applicable) 

1 PPS 

5 

Note: 

1. National frequency(ies) allocations will determine the final IC2DL frequency 

2. UDP was chosen in order to be compatible with STANAG 4586 


Remarks : 

1) We specify BER at 10" 6 (Section F. 1.3.1) for all operating conditions as the 
minimum performance (worst case). 

2) We agree this is a system dependent parameter particularly when the level of 
autonomy is not discussed. However, we also refer to NAS-SR-100 as the 
performance guideline (Section F. 1.1.1) to consider safe separation and 
control of the UA. 

3) We concur. In our case, we also point out our condition which is HALE 
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UAS above FL430 (Section F.1.6). 

4) As in its own note, the frequency must be approved by the respective nation. 
In our case, we require FCC/FAA approval (Section FI. 1.3). 

5) We consider this is a design-specific parameter and hence not addressed. 

6) We have proposed a minimum capacity of 64 Kbps per UA (Section 1.1.2b). 
The data rate in the IC2DL table is the network data rate. The real data 
capacity per node or circuit is much lower than 300 Kbps. As a matter of 
fact, it is suggested 75 Kbps per uplink or downlink in Table B-7 of the same 
IC2DL document (page B-42). The information exchange (IER) requirement 
table in Attachment 1 of STANAG 4660 conveys the baseline rationale for 
the rate requirement. 

7) We consider security as one of the primary concerns. Therefore, we 
recommend Federal Information Processing Standard (FIPS) 197 as the 
minimum performance guideline (Section F.1.4). 

8) Instead of failing the attempt to specify a number in the table, we state it as a 
functional requirement (Section 4.3.4. 1). The number is a design parameter 
that may be coordinated with or traded off against other design issues. 

9) This parameter is related to the end-to-end message transfer delay in our 
document. We state “The equipment delay ranges from 20 ms to 50 ms that 
is achievable.” (Section F. 1.3.2) This is pretty consistent with 50 tolOO ms 
when the network framing factor is included. The Launch and Recovery 
phase needs the most demanding requirement. We do not address any sensor 
related functions and performance. 

10) We include this factor in the functional requirements (Section 4.3.2). 
According to their own note, they specify the protocol in order to be 
compatible with STANAG 4586. We do not have the same constraint. 

In summary, the high level performance requirements recommended in 

STANAG 4660 are consistent with and close to the performance guidelines 

proposed in Appendix F. Both performance recommendations were developed 

independently and the findings of STANAG 4660 support our recommendations. 
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